The proliferation of distributed computing networks has brought with it a greater need to secure the information that is transmitted through the networks. Moreover, with higher integration of electronic circuits on smaller Integrated Circuits (ICs), electronic components are increasingly capable of processing more complex data and performing more functions. ICs within the same digital system, for example, a Personal Computer (PC), a set-top box, or a mobile phone are communicating more security sensitive data to/from other ICs within the same system. Furthermore, these ICs are increasingly being used to store, process, and communicate sensitive data. Therefore, the data stored and communicated by these ICs need to be secured.
A variety of cryptographic techniques are known for securing transactions in data networks. For example, the Secure Socket layer (SSL) protocol and its successor Transport Layer Security (TLS) provides a mechanism for securely sending data between a server and a client. Briefly, the SSL provides a protocol for authenticating the identity of the server and the client and for generating an asymmetric (private-public) key pair. The authentication process provides the client and the server with some level of assurance that they are communicating with the entity with which they intended to communicate. The key generation process securely provides the client and the server with unique cryptographic keys that enable each of them, but not others, to encrypt or decrypt data they send to each other via the network. SSL involves a number of basic phases: Peer negotiation for algorithm support, Public-key encryption-based key exchange and certificate-based authentication, and Symmetric cipher-based traffic encryption.
FIG. 1 shows, in simplified form, several layers in a security system 102. Entities in the system may securely transfer data between one another by encrypting the data 104 before it is transmitted. Before another entity is able to decrypt received data, however, it must obtain an appropriate key. Hence, data encryption depends on a secure method of key negotiation 106 between the entities. If the key negotiation is not secure (e.g., the keys are subject to interception by unauthorized persons), the encrypted data may be compromised. Likewise, a prerequisite to secure key negotiation is the ability to authenticate the parties 108 involved in the exchange. In other words, each entity must be sure that it is not negotiating with an entity that is, for example, masquerading as the intended entity (middle man attack). The authentication process ultimately relies on a root key 110 that uniquely and reliably identifies a specific entity. Hence, this root key is often referred to as the cryptographic identity of the entity.
In practice, a root key is used to generate other keys that may then be used to generate even lower level keys. Typically, these lower level keys will be used for relatively short periods of time. For example, lower level keys such as SSL session keys may be valid only for a single session. Thus, the potential for damage may be much less in the event a session key is compromised as opposed to a higher level key. For example, in the case of a security breach, the entire system will not be compromised and the key will expire relatively quickly.
In contrast, once a higher level key is compromised, all subsequent (e.g., lower) levels may be compromised. Moreover, higher level keys tend to be used for relatively long periods of time. Thus, the potential for harm is much greater. Accordingly, protection of higher level keys is a primary goal in any cryptographic security system.
For example, in a typical e-commerce transaction a unique set of SSL keys are generated for each session. For instance, when a user uses a web browser to securely access a financial website for a bank, a set of session keys may be generated for the session. These session keys are used to encrypt and decrypt data sent between the server (e.g., the bank's server) and the client (e.g., the browser). To prevent these keys from being intercepted by unauthorized persons, a higher level key (e.g., a private-public key pair negotiated between the bank's server and the client) will be used to encrypt and decrypt the session level keys. As discussed above, however, protection of this higher level key is of utmost importance.
Referring to FIG. 2, in a typical PC-based application, a client device stores its private key (Ka-priv) 214 in a system memory 206 of the computer 200. When a session is initiated, the server encrypts the session key (Ks) 228 using the client's public key (Ka-pub) then sends the encrypted session key (Ks)Ka-pub 222 to the client. As represented by lines 216 and 224, the client then retrieves its private key (Ka-priv) and the encrypted session key 222 from system memory via the PCI bus 208 and loads them into a public key accelerator 210 in an accelerator module or card 202. As represented by line 226, the public key accelerator uses this downloaded private key 220 to decrypt the session key and loads the clear text session key (Ks) 228 into system memory.
When the server needs to send sensitive data to the client during the session the server encrypts the data using the session key (Ks) and loads the encrypted data (data)Ks 204 into system memory. When a client application needs to access the plaintext (unencrypted) data, it may load the session key 228 and the encrypted data 204 into a symmetric algorithm engine (e.g., 3DES, AES, etc.) 212 as represented by lines 230 and 234, respectively. The symmetric algorithm engine uses the loaded session key 232 to decrypt the encrypted data and, as represented by line 236, loads plaintext data 238 into system memory. At this point the client application may use the data.
The SSL protocol and other protocols provide a relatively high level of security for data transfers over a computer network, when both the client and the server are secure. However, given the increased sophistication of hackers and authors of computer viruses, there is a possibility that the security of these devices may be comprised. For example, a virus running on a computer may be able to access data stored in the data memory of the computer. Moreover, the virus may be able to send this information to a third party.
Referring again to the example of FIG. 2, the client's private key (Ka-priv) may be stored in the clear (e.g., unencrypted) in system memory and it may be transmitted in the clear across the PCI bus. Moreover, operating system calls may be used to provide the data transfers to and from the cryptographic accelerator. All of these aspects of the system are susceptible to attacks by hackers, viruses or other means. Given that in an SSL transaction the client's private key is essentially a certificate that identifies the server (hence it may essentially comprise the server's private key), conventional architectures such as this may not provide sufficient security for many applications.
Components such as a hardware security module (“HSM”), typically constructed as multi-chip boards, may be used to provide a higher level of security for highly security-sensitive applications. Conventionally, a hardware security module provides secure key management to generate cryptographic keys, sets the capabilities and security limits of keys, implements key backup and recovery, prepares keys for storage and performs key revocation and destruction.
However, these hardware modules or devices are not per se authenticated. It is typically the application that runs on these devices that is authenticated for ensuring data security among different applications that exchange data. Moreover, even the most sophisticated data security schemes are prone to security breaches at the component level. For example, a system may be probed at the component level (that is at the printed circuit board “PCB” level) to sniff a root (private) key. Once the private key is stolen, access to encrypted information becomes substantially easier. In some systems, the components are physically contained and made inaccessible, for example, by covering them with a thick layer of plastic type material. This approach may prevent unauthorized access to the components by probing the component pins or printed wires, for example, using a logic analyzer. However, this approach makes testing, debugging and repairing of the PCBs unreasonably difficult.
Accordingly, there is need for improved security in a digital system/device at the electronic component level that does not require any outside or remote server/entity to secure data communication in the digital system/device.